调料|信息源_MVI到底是不是凑数的？通过案例与MVVM进行比较

篇首语：本文由编程笔记#小编为大家整理，主要介绍了MVI到底是不是凑数的？通过案例与MVVM进行比较相关的知识，希望对你有一定的参考价值。

前言

最近看到不少介绍MVI架构&＃xff0c;即Model-View-Intent的文章&＃xff0c;有人留言说Google炒冷饭或者为了凑KPI“发明”了MVI这么一个词。和后端的朋友描述了一下&＃xff0c;他们听了第一印象也是和MVVM好像区别不大。但是凭印象Google应该还没有到需要这样来凑数。

去看了一下官网&＃xff0c;发现完全没有提到MVI这个词。。但是推荐的架构图确实是更新了&＃xff0c;用来演示MVI也确实很搭。

&＃xff08;官网图&＃xff09;

想了想&＃xff0c;决定总结一下自己的发现&＃xff0c;和掘友们一起讨论学习。

一丶案例分享

看过一些分析MVI的文章&＃xff0c;里面实现的方法各种各样&＃xff0c;细节也不尽相同。甚至对于Model边界的划分也会不一样。

下面先分享一下在特定场景下我的MVVM和MVI实现&＃xff08;不重要的细节会省略&＃xff09;。

1.1.场景

先预设一个场景&＃xff0c;我们的界面&＃xff08;View/Fragment&＃xff09;里有一个锅。主要任务就是完成一道菜的烹饪&＃xff1a;

几个需要注意的点&＃xff1a;

• 初始状态&＃xff1a;开火
• 加入材料时&＃xff1a;都是异步获取材料&＃xff0c;再加入锅中
• 结束状态&＃xff1a;出锅

本文主要是比较MVVM和MVI&＃xff0c;这里只分享这两种实现。

1.2.经典MVVM

为了加强对比&＃xff0c;这里的实现比较接近android Architecture Components刚发布时官网的的代码架构和片段&＃xff1a;

&＃xff08;当时的官网图&＃xff09;

// PotFragment.kt
class PotFragment
...
// 观察是否点火
viewModel.fireStatus.observe(
viewLifecycleOwner,
Observer
updateUi()
if (fireOn) addOil()

)
// 观察油温
viewModel.oilTemp.observe(
viewLifecycleOwner,
Observer
updateUi()
if (oilHot) addIngredients()

)
// 观察菜熟没熟
viewModel.ingredientsStatus.observe(
viewLifecycleOwner,
Observer
updateUi()
if (ingredientsCooked)
// 加调料
addPowder(SALT)
addPowder(SOY_SAUCE)


)
// 观察油盐是否加完
viewModel.allPowderAdded.observe(
viewLifecycleOwner,
Observer
// 出锅!

)
viewModel.loading.observe(
viewLifecycleOwner,
Observer
if (loading)
// 颠勺
else
// 放下锅


)
// 一切准备就绪&＃xff0c;点火
turnOnFire()
...
// PotViewModel.kt
class PotViewModel(val repo: CookingRepository)
private val _fireStatus &＃61; MutableLiveData()
val fireStatus: LiveData &＃61; _fireStatus
private val _oilTemp &＃61; MutableLiveData()
val oilTemp: LiveData &＃61; _oilTemp
private val _ingredientsStatus &＃61; MutableLiveData()
val ingredientsStatus: LiveData &＃61; _ingredientsStatus
// 所有调料加好了才更新。这里Event内部会有flag提示这个LiveData的更新是否被使用过
//&＃xff08;当年我们还真用这种方式实现过单次消费的LiveData&＃xff09;。
private val _allPowderAdded &＃61; MutableLiveData>()
val allPowderAdded: LiveData> &＃61; _allPowderAdded
// 假设已经实现逻辑从repo获取是否有还在进行的数据获取
private val _loading &＃61; MutableLiveData()
val loading: LiveData &＃61; _loading
fun turnOfFire()
// 假设下面都是异步获取材料&＃xff0c;这里简化一下代码
fun addOil()
repo.fetchOil()

fun addIngredients()
repo.fetchIngredients()

fun addPowder(val powderType: PowderType)
repo.fetchPowder(powderType)
// 更新_allPowderAdded的逻辑会在这里

...


特点&＃xff1a;

• 使用多个LiveData观察不同的数据&＃xff0c;并以此来更新UI。每个LiveData都是一个State&＃xff0c;每个View有自己的State。
• UI是否显示loading由Repository决定&＃xff08;是否有正在进行的数据读取&＃xff09;。
• 对于观察的LiveData要做出何种操作&＃xff0c;UI层的逻辑代码往往无法避免。

很久以前也听说过用状态机&＃xff08;state machine&＃xff09;管理UI界面&＃xff0c;但是思路还是限制在使用多个LiveData&＃xff0c;使用时进行合并。虽然状态更清晰了&＃xff0c;但是对于代码的可维护性并没有明显的帮助&＃xff0c;甚至ViewModel里还多了些合并LiveData以及状态管理的代码。代码貌似还更复杂了。后来发现了Redux式的思路&＃xff0c;才有了下面这个版本的MVI实现。

1.3.MVI

下图是我对这个思路的理解&＃xff1a;

• 单一信息源
• 单向/环形数据流

定义几个下面代码会用到的名称&＃xff08;不用细究命名&＃xff0c;只要自己和团队觉得有意义叫什么都行&＃xff09;&＃xff1a;

• State&＃xff1a;不管数据从哪里来&＃xff0c;经过什么处理&＃xff0c;都会归于现在的状态。
• Event&＃xff1a;上图中的意图产生或代表的事件&＃xff0c;也可以理解为Intent或者Action&＃xff0c;最终产生Event让我们更新State。
• Reducer&＃xff1a;驱动状态变化的核心。这个例子里可以想象成厨师的手&＃xff0c;用来改变锅的状态。
• Side effects&＃xff1a;用户无感知&＃xff0c;就当它是“额外效果”&＃xff08;或者“副作用”&＃xff09;。对于数据的请求或者记录上传用户操作的代码都归于此类。

下面开始展示伪代码&＃xff1a;

// PotState.kt
sealed class PotState
object Initial: CookingStatus()
object FireOn: CookingStatus()
class Cooking(val data: List): CookingStatus()
object Finished: CookingStatus()
// CookEvent.kt
sealed class CookEvent
object TurnOnFire(): CookEvent()
object RequestOil(): CookEvent()
object AddOil(): CookEvent()
class RequestIngredient(val ingredientType: IngredientType): CookEvent()
class AddIngredient(val ingredient: Ingredient): CookEvent()
class RequestPowder(val powderType: PowderType): CookEvent()
class AddPowder(val powder: Powder): CookEvent()
object ServeFood()
// models.kt
interface EdibleStuff
data class Oil(...) implements EdibleStuff
data class Ingredient(...) implements EdibleStuff
data class Powder(...) implements EdibleStuff
// PotReducer.kt
class PotReducer
fun reduce(state: PotState, event: CookEvent) &＃61;
when (state)
Initial -> reduceInitial(event)
FireOn -> reduceFireOn(event)
is Cooking -> reduceCooking(event)
Finished -> reduceFinished(state, event)

// 每个状态只接受某些特定的Event&＃xff0c;其它的会忽略&＃xff08;无法影响当前状态&＃xff09;
private fun reduceInitial(state: PotState, event: CookEvent) &＃61;
when (event)
TurnOnFire -> flowOf(FireOn) // 生成一个Cooking状态并加好油
else -> // handle exception

private fun reduceFireOn(state: PotState, event: CookEvent) &＃61;
when (event)
AddOil -> flowOf(Cooking(mutableListOf(Oil)) // 生成一个Cooking状态并加好油
else -> // handle exception

private fun reduceCooking(state: PotState, event: CookEvent) &＃61;
when (event)
AddIngredient -> flowOf(state.apply data.add(event.ingredient) ) // 加菜
AddPowder -> flowOf(state.apply data.add(event.powder) ) // 加调料
else -> // handle exception

private fun reduceFinished(state: PotState, event: CookEvent) &＃61;
when (event)
ServeFood -> flowOf(Finished) // 出锅
else -> // handle exception

// PotViewModel.kt
class PotViewModel(val potReducer: PotReducer, val repo: CookingRepository)
...
var potState: PotState &＃61; Initial
// 生成下一状态&＃xff0c;更新Flow
fun processEvent(event: CookEvent) &＃61;
potReducer.reduce(potState, event)
.updateState()
.handleSideEffects(event)
.launchIn(viewModelScope)
// 对于不直接影响UI的事件&＃xff0c;当做side effects处理
private fun handleSideEffects(event: CookEvent) &＃61;
onEach event ->
when (event)
is RequestOil -> fetchOil()
is RequestIngredient -> fetchIngredient(...)
is RequestPowder -> fetchPowder(...)


// 收到Repository传来的食料&＃xff0c;启动新Event&＃xff1a;添加入锅
private fun fetchOil() &＃61; repo.fetchOil().onEach processEvent(AddOil) .collect()
// fetchIngredient(...) 与 fetchPowder(...) 也类似
...
// PotFragment.kt
class PotFragment
...
&＃64;Composable
fun Pot(viewModel: PotViewModel)
val state by viewModel.potState.collectAsState()
Column
//Render toolbar
Toolbar(...)
//Render screen content
when (state)
FireOn -> // render UI
is Cooking -> // render UI
Finished -> // render UI&＃xff1a;出锅!



// 准备就绪&＃xff0c;挑个合适的时机开火
viewModel.processEvent(TurnOnFire)
...


特点&＃xff1a;

• Fragment/Activity只负责渲染
• 用户意图会产生Event&＃xff0c;并被ViewModel中的Reducer处理
• 特定的状态下&＃xff0c;只会接收能被处理的Event

二丶分析

2.1.经典MVVM

优点&＃xff1a;

• 相比MVC或者MVP&＃xff0c;相信大家都熟悉。

缺点&＃xff1a;

• 每个View有自己的State。很多View混合在一起时&＃xff0c;代码和我们的思路都容易变混乱。审核代码也需要对全局有很好的理解。
• 需要观察的数据多了之后&＃xff0c;LiveData管理可以变得很复杂。
• 可以看到&＃xff0c;Fragment中无论何时都在观察并接收所有LiveData的更新。仔细想想&＃xff0c;其实这当中是包含了一些逻辑的。比如说&＃xff0c;开火之后我们不希望接收加调料的操作。这些逻辑不容易单独拿出来写测试&＃xff0c;通常要被包含在Fragment的测试离。

2.2.MVI

优点&＃xff1a;

• State是single source of truth&＃xff0c;单一信息源&＃xff0c;不用担心各个View的状态到处都是&＃xff0c;甚至相互冲突。
• 伴随着预设的状态值&＃xff0c;可以接受的意图Intent或者操作Action也可以预设。不在计划里的意图/操作不会对UI界面产生影响&＃xff0c;也不会有额外效果。审核代码只需要了解新增的意图对某一两个受影响的状态就足够&＃xff0c;不用把整个界面的内容都复盘一遍。单元测试也是类似。也算是符合关注点分离&＃xff08;Separation of Concerns&＃xff09;。

缺点&＃xff1a;

• 随着View变得复杂&＃xff0c;可以有的状态以及能接受的意图也会迅速膨胀。
• 文件数量变多&＃xff08;这个和从MVC到MVP的感觉有点像&＃xff09;。
• 新手学习、理解起来不容易。

2.3.比较

两种架构都有优缺点。

因为大家都熟悉MVVM&＃xff0c;新团队的接受度肯定会好。

有些缺点也可以想办法改进。例如MVI的状态膨胀可以通过划分为几个小的分状态来缓解。

对于复杂的场景&＃xff0c;我个人更倾向于采用MVI的全局状态管理的思路。主要还是觉得传统MVVM每次添加新的LiveData时&＃xff08;当然现在常常用Flow&＃xff09;&＃xff0c;需要仔细检查其它所有的View或者LiveData&＃xff0c;生怕漏掉什么改动&＃xff0c;不利于高效开发和维护。

三丶总结

我认为传统的MVVM和MVI主要的区别还是在于全局状态管理。而且这个全局状态管理的思路用传统MVVM架构也能实现&＃xff0c;很多人觉得MVI和MVVM差不多的原因可能正是如此。 其实也不足为奇&＃xff0c;不少设计模式两两之间也很相似&＃xff0c;但并不妨碍大家给他们安上不同的名字。只要我们把握住核心概念&＃xff0c;合理运用&＃xff0c;叫什么名字也不重要。正如官方的建议&＃xff1a;

就算叫MVI只是为了唬人&＃xff0c;让人一听到就知道你运用了Redux/State machine的思路&＃xff0c;而不是“经典”的安卓版MVVM&＃xff0c;好像也是个不错的理由。

题外话

从官网架构图的变化产生的联想&＃xff1a;

ViewModel 化身 LifecycleObserver

最近看到不少文章分享他们对于让ViewModel也lifecycle-aware的实验。从官方文档看&＃xff0c;UI elements和State holders&＃xff08;在我看来就是Fragment/Activity和ViewModel&＃xff09;也在被视作一个整体的UI Layer。不知道以后是不是会有这么一个趋势。

有时候&＃xff0c;不经意间就会错过一些有趣实用的想法。回想2017年的时候&＃xff0c;听到WeWork的员工分享他们自制的Declarative UI库。当时觉得都不能预览&＃xff0c;应该不会好用到哪去吧。没想到后来官方发布了Compose&＃xff0c;预览功能都加入了Android Studio。

选择性使用的 Domain Layer

也许是随着这几年Clean Architecture的热度上升&＃xff0c;看到不少团队开始加入领域层。官方推荐的架构图&＃xff08;开头提到&＃xff09;中也加入了Domain Layer (optional)。添加这么一层的确可以帮助我们解耦部分逻辑。

作者&＃xff1a;厨师小p
链接&＃xff1a;https://juejin.cn/post/7090200118431121416
来源&＃xff1a;稀土掘金
著作权归作者所有。商业转载请联系作者获得授权&＃xff0c;非商业转载请注明出处。